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Field of the invention 

5 The present invention relates to multicast services for mobile networks. The present in- 
vention also relates to system components in mobile networks rendering such multicast 
services possible. More specifically the invention relates to muittcasting in a GPRS net* 
work. 

10 Background of the invention 

As is known, unicast is a point-to-point distribution, whereby one stream of data exists 
per recipient on every link connecting a given recipient and the source. 

15 Multicasting is a sen/ice that permits a source to send a message to a plurality of spe- 
cific recipients. The notion multicasting ideally involves that only one copy of the mes- 
sage will pass over any link in a network and copies of the message will be made only 
where paths diverge. From a network perspective, multicasting dramatically reduces 
overall bandwidth consumption, since data is replicated in the network at appropriate 

20 points. 

Receivers join a particular multicast session group by informing a corresponding multi- 
cast router whereby traffic is delivered to all members of that group by the network infra- 
structure. The transmission can be performed either from one user to many users, the 
25 so-called one-to-many multicast or many users send information to many receivers, the 
so-called many-to-many transmission. 

For typical local area networks, LAN, utilising CSMA (Carrier Sense Multiplex Access) 
where nodes share a common communication medium, multicasting is easy to support. 
30 A specially addressed packet can be read off the communication medium by multiple 
hosts. Ethernet, for instance, supports uni-cast addresses, multicasting addresses and 
the network broadcast address. 

Extending multicasting capabilities to inter-networks however led to the introduction of a 
35 router at the edge of a network in order to figure out dynamically how to fonrt^ard the da- 
tagram, whereby a datagram denotes a data packet, which is established on the IP 

1 
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layer. The way of forwaixling is deducted from the address included in the header of the 
datagram and from the routing table, which is administrated by the router. 

With Internet Protocol IP multicast, receivers do not need to know who or where the 
5 senders are and senders do not need to know who the receivers are. Neither senders 
nor receivers need to care about the network topology as the network optimises delivery. 
The distribution of information via IP multicast is performed on the base of a hierarchical 
connection of the hosts, like for example a tree. Several algorithms have been proposed 
for building multicast distribution trees, like for example spanning trees, shared-trees, 
10 source-based trees, core-based trees. The descriptions of the corresponding algorithms 
can be found in ^IP telephony: Packet-based multimedia communications systems** O. 
Hersent, D. Gurte, D.Petit, Addison-Wesley , Harlow, 2000. After the establishment of the 
distribution tree, the distribution of the information is done by the IP multicast routing 
protocols. 

15 

A specific IP multicast address denotes that a given datagram belongs to a multicast 
group rather than the addresses of individual recipients, as is the case with normal IP 
addresses. There are various possibilities of assigning multicast addresses to multicast 
groups. The task of a given multicast router is to encode the destination addresses and 
20 to route multicast datagrams according to information in its routing table. 

For IP multicast, the membership of a multicast session group may be dynamic, that is, 
hosts may join and leave groups at any time. Hence, multicast routers need to update 
information on which other hosts and routers are present memt)ers of a given multicast 
25 group. 

The Internet Group Management Protocol, IGMP, is a protocol that allows inter-domain 
routing of IP multicast data. Multicast routers use IGMP to learn which multicast groups 
have members on each of their attached physical networks. IGMP allows group termina- 
30 tion to be quickly reported to the routing protocol, which is important for high-bandwidth 
multicast groups and sub-nets with highly volatile group membership. 

According to IGMP, multicast routers periodically send a General Query to the all sys- 
tems multicast group (224.0.0.1) (address) in order to determine if other multicast 
35 routers are present on the segment. A mechanism secures that only one multicast router 
adopts the state of Querying multicast router on a given segment. The querying router 

2 
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issues Group Specific Queries. In response, hosts send a Membership Report, infomiing 
whether the host is a member of the particular multicast group to the Querying router. 
When a router on the other hand receives a Report, it adds the group being reported to 
the list of multicast group memberships on the network on which it received the Report 
5 and sets a timer for membership. When a host joins a multicast group, it immediately 
transmits an unsolicited membership report. IGMP has been specified in Network Work- 
ing Group RFC 2236. 



Multicast Listener Discovery, MLD, is an alternative protocol to IGMP that allows the use 
10 of IPv6 (Internet Protocol version 6). In MLD, a Multicast Listener Report message cor- 
responds to the Membership Report of IGMP. Furthermore according to MLD, the mes- 
sage Multicast Listener Done, corresponds to a Membership Report. MLD is specified in 
Network Working Group RFC 2710. 

Currently there is activity within the 3'rd generation partnership project, 3GPP, regarding 
the introduction and support of multicast sen/ices in packet data mobile systems. 

According to known GPRS and UMTS networks, the mobile terminated down-link traffic 
is routed using identities which are designed to only handle point to point traffic. 

As is known in the art, in order to perform unicast transport, a data structure denoted 
mobility management (MM) context exists in the mobile station and the SGSN. Moreo- 
ver, a Packet data protocol (PDP), context, which e.g. comprises an IP address for al- 
lowing the mobile station to participate in an IP session with an Internet sen/ice provider 
exist at the mobile station, the SGSN and the GGSN. 

The technical background about GPRS in GSM and UMTS is covered in the following: 

3GPP TS 03.60 V7,5.0 (2001-01) 3rd Generation Partnership Project; 
30 Technical Specrfication Group Services and System Aspects, 
Digital cellular Telecommunications System (Phase 2+), 
General Packet Radio Service (GPRS), 
Service Description, Stage 2 (Release 1998). 



15 



20 



25 
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3GPP TS 23.060 V3.6.0 (2001-01) 
3rd Generation Partnership Project; 

Technical Specification Group Services and System Aspects, 
General Packet Radio Service (GPRS). 
5 Sen/ice Description, Stage 2 (Release 1999). 



Summary of the invention 

10 

The present invention achieves a more efficient multicast transmission in General 
Packet Radio Networks, more specifically those portions of the GPRS network according 
to 3GPP specifications that are denoted the Gn, Gp and the lu-PS interface. 

15 It is a first object of the invention to make it possible to introduce multicast services in 
mobile networks, such that resources are used efficiently. That is, transmitting informa- 
tion to a large group of receivers simultaneously while utilising a minimum of bandwidth. 

This object has been accomplished by the method defined by claim 1 . 

20 

It is another object to introduce a gateway node for obtaining multicast messaging in a 
packet radio data network. 

This object has been achieved by the subject matter of claim 3. 

25 

It is another object to introduce a serving node for obtaining multicasting in a packet ra- 
dio data network. 

This object has been achieved by the subject matter of claim 5. 

30 

It is another object to set forth a mobile station establishing a multicast service in a 
packet radio data network. 

This object has been achieved by the subject matter defined by claim 12. 

35 
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Further advantages will appear from the following detailed description and the drawings 
of the invention. 



5 Brief description of the drawings 

Fig. 1 shows multicast packet flows in an exemplary GPRS communication network ac- 
cording to a first embodiment of the invention, 

10 Fig. 2 shows multicast packet flows in an exemplary GPRS communication network ac- 
cording to a second embodiment of the invention, 

Fig, 3 is a schematic representation of a preferred procedure for activation of a multi* 
point session according to a preferred embodiment of the invention, 



15 



Fig. 4 is a flow diagram for the GGSN according to the invention, and 



Fig. 5 is a flow diagram for the SGSN according to the invention. 



20 
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The present invention allows several users to listen to multicast transmissions in a wire- 
less network and more specifically a GPRS network. This concept comprises an applt- 
5 cation level multicast session with the following properties: 

The transmission is simplex, unidirectional, sent from one source to many end users, 
located at one or many geographical sites. There is one source and many end users. 
The user must register to the service to get the information needed (e.g. decoding, ci- 
10 phering key etc.) for the terminal to listen to the transmission via a data structure, de- 
noted multicast context, which several users can share. The multicast context relates to 
various parameters or data for a mobile station involved in a given session and com- 
prises data about e.g. multicast group address, APN used, QoS. 

15 The multicast context is a data structure that - unlike the MM context and PDF context - 
is not associated with a specific mobile station but with a specific multicast group. The 
multicast context is created in a given node when there is at least one member for the 
multicast group in the area sen/ed by the node, 

20 The multicast context contains a list of the current members of the multicast group. The 
list points to the PDF context of each member. From the PDP context of the members, 
the current location of the members can be found. 

From the multicast context, the SGSN and the GGSN derives routing tables, which en- 
25 able the desired forwarding and possible replication of multicast data packets to be per- 
formed. Thereby, multiple mobile stations can receive the multicast context from the 
same stream. 

Whenever multicast group members are added or removed or change locations, it is 
30 checked whether routing table entries should be added or removed. 

The user may be notified of the presence of a certain multicast transmission, either by 
an active search for available sen/ices in a certain area, e.g. via a web page, or by get- 
ting information about the service via e.g. SMS or a push service. 

35 
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Dynamic multicast tree 

In frg. 1, an exemplary diagram relating to a GPRS network has been shown whereby 
the multicasting according to a first embodiment of the invention has been shown. In the 
5 given example a number of mobile stations Ml - M10 are wirelessly connected to a 
number of base stations, also denoted radio access nodes (RANI * RAN5). The RAM's 
are coupled to respective Serving GPRS Support Nodes (SGSN1, SGSN2), which then 
again are coupled to a Gateway GPRS Support Node (GGSN). A multicast source 
(MCS) is coupled to the GGSN and delivers for instance various multicast services such 
10 as streaming video and audio. An Internet Service Provider may accommodate the mul- 
ticast source but the multicast source may also reside with the Gateway GPRS Support 
Node. 

Packet streams are routed in the GGSN, SGSN1 and SGSN2 and RAN1 - RAN5, by 
15 means of routing tables. An excerpt of routing tables has been shown in the present ex- 
ample, namely routing table RTR10 relating to RANI. RTR20 relating to RAN2. RTR30 
relating to RAN3 and RTS10 relating to SGSN1 . 

In the present example, the mobile stations Ml, M4 and M7 wishes to receive multicast 
20 services of a multicast group MG7. Moreover, mobile stations M3 and M9 wishes to re- 
ceive multicast services of a multicast group MG8. 

It should be noted that in a real system, a higher number of mobile stations would typi- 
cally be present. Moreover, many more services would be demanded and more QoS 
25 classes would be provided, either as individual multicast groups or by means of quality 
layering. However, for illustrative purposes the above simple example has been chosen. 

According to a first embodiment of the invention, the GPRS tunnel protocol (GTP) ren- 
ders the multicast connectivity possible. A GTP tunnel is a two-way, point to point path. 
30 By encapsulating a packet or a stream of IP packets with a tunnel specific header, data 
is tunnelled to a tunnel endpoint. In the following, the term multicast tunnel will be used 
for referring to a GTP tunnel that is adapted to carry an IP stream of multicast content, 
that is, content which potentially can or will be received by a plurality of end points. 

35 According to the exemplary fig. 1 , a set of first multicast GTP tunnels, denoted GTPT7, 
is set up between GGSN1 and SGSN1 and between SGSN1 and RANI as well as be- 

7 
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tween SGSN1 and RAN3. The GTP tunnels correspond to an encapsulation of the data 
stream with appropriate headers. 

The multicast tunnel GTP7 carries the IP packet stream relating to multicast group 7. 
5 MG7, from GGSN1 to SGSN1. from where it is cast to RAN1 and RAN3. respectively. 
For this purpose, the data stream is encapsulated with a header comprising the ad* 
dresses of SGSN1, and subsequently new headers corresponding to RANI and RAN3 
are added. 

10 in analogy with the above, tunnel GTPT8 carrying stream IPSTR8 is transmitted to mo- 
bile stations MS and M9 being memt)ers of multicast group MG8. Tunnel GTPT8 carry- 
ing IP Stream iPSTRS is replicated in GGSN1 and transmitted to SGSN1 and SGSN2. 
Tunnels 

15 Routing tables RTR10, RTR20 and RTR30, secure that the various streams are pro* 
vided to only those respective mobile stations which subscribe to the given multicast 
group. 

It is noted that the GGSN and SGSN does not examine the content of the tunnels (pack- 
20 ets), but that the SGSN just redirects the tunnels according to the routing table in the 
respective entity. 

Hence, a POP type multipoint service, which enables the above multicasting traffic, has 
been set forth. 

25 

Static multicast tree 

As an alternative to the above dynamic multicast tree, the GTP tunnels carrying the mul- 
ticast content can also be pre-configured to be rendered availabie to a number of pre- 

30 determined nodes in the GPRS network. The predetermined nodes could correspond to 
a given regional area. In fig. 2 such a static multicast tree has been shown whereby mul- 
ticast content corresponding to multicast groups MG7 and MG8 are distributed via GTP 
tunnels to RAN1 , RAN 2 and RAN3. Hence, subscription to these services will only be 
available to terminals being in the cells corresponding to the above radio access net- 

35 works. 
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Such a service would be relevant for geographically oriented content such as local ad- 
vertisements or traffic information or information regarding a local event happening at a 
specific venue such as e.g. a sports stadium. 

5 In case static multicast trees are used, the SGSN and/or RANs must ignore the multicast 
data if no clients are registered for the corresponding multicast group. 

IP multicast in core network 



10 instead of using multicast GTP tunnels as described above, IP multicast capabilities of 
the IP transport network between GGSN and SGSN can be utilised, whereby lower level 
nodes register to higher level nodes (e.g. a SGSN registering to the GGSN) and da- 
tagrams are distributed by IP multicast, in this manner, the connections of the multicast 
tree are based on memberships to IP multicast addresses. 

15 

This is an optional enhancement, which can further optimise the transmission of multi- 
cast data. The above option allows for dynamic and pre-configured multicast delivery 
trees. 

20 Activation of the service 

According to the Invention, the multicast application in the mobile station is using IP mul- 
ticast, and therefore sends an IGMP (internet Group Management Protocol. RFC 2236) 
membership report message (MLD, Multicast Listener Report. RFC 2710, in case of 
25 Ipv6), when it wants to join a multicast group. This message is received in the GGSN. 

If necessary, the GGSN attaches to the multicast delivery tree of the multicast source 
with the appropriate (multicast routing) protocol. Based on information in the message 
from the mobile station and information from the mutticast source the GGSN can update 
30 the quality of service parameters for the context for the mobile station and if necessary 
update the multicast tree. 

The multicast service can be provided by e.g.. a content provider, either directly to a 
number of GGSNs, or via IP Multicast. The user may be notified of the presence of a 
35 certain transmission, either by active search for available services in a certain area, e.g. 

9 



>ISDOClD: <WO 03036872A1 I > 



wo 03/036872 PCT/SE02/01799 

via a web page, or by getting information about the service via e.g. SMS or a push serv- 
ice, e.g. via Session Announcement Protocol (SAP). 

The end-user can be notified of the multicast transmissions e.g. via push services or 
5 web surfing. 

The procedure for establishing the multicast session shall now be further explained with 
reference to fig. 3: 

10 Before the procedure can be initiated, the mobile station needs to have established a 
PDP context for IP. 

1 . The mobile terminal informs the GGSN of its interest for a specific multicast sen^ice. 
15 The mobile terminal issues a membership report message such as (GMP or MLD in 

case of Ipv6. The message may or may not contain information about the desired quality 
of service. 

20 2. The GGSN validates the request from the mobile terminal and if necessary registers 
for the multicast service requested. 

The GGSN may decide the quality of service to use for the distribution of the multicast 
group based on information from the source, operator settings and/or the mobile termi- 
25 nai. 

The GGSN sends a multicast context activation message to the SGSN. The message 
contains the identity of the user, the address of the multicast group and the quality of 
service that should be used for the given multicast group. Optionally the GGSN uses 
30 point-to-point links to the MS if the SGSN is not capable of handling multicast informa- 
tion. 

Following the procedure of GGSN-lnitiated PDP context modification, the Update PDP 
context request signalling message could be used for this. 

35 
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3. The SGSN informs the radio access network that the mobile station is joining this 
multicast group, so that the proper radio access bearer can be set up for the given multi- 
cast session. 

5 This signalling message is dependent on whether there already in this part of the multi- 
cast tree is a mobfie station Kstenmg to or being a member of the given multicast group. 
If another mobile station already listens to the given multicast group, a link (GTP tunnel 
or IP multicast connection) of the multicast tree may already be established for this mul- 
ticast group here. 

10 

If no link of the tree is established, the desired link is added to the multicast tree between 
the SGSN and the RAN. 

15 4. The SGSN updates the context for the mobile station with the multicast group and its 
quality of service and used APN. 

In case the Radio Access Network does not support any multicast radio t>earers, this 
message is not send. The SGSN performs a packet replication and fonA^ards packets 
20 using a previously established point-to-point radio access bearer. 

The SGSN replies to the GGSN, whereby the SGSN, if not already a part, becomes a 
part of the multicast tree* 

25 

5. The SGSN notifies the mobile station of the radio access bearer and quality of service 
defined for the multicast session. 

The GGSN-lnitiated PDP context modification procedure could be used for this purpose. 
30 In that case, the Modify PDP context request signal is used. 

In case the mobile terminal does not support any multicast radio access bearer^ the 
SGSN carries out the packet replication and forwards packets using the already estab- 
lished point-to-point radio access bearer. In this case, the SGSN does not explicit notify 
35 the mobile station. 

11 



^JSDOCID: <WQ 



03036872A1J_> 



wo 03/036872 PCT/SE02/01799 

6. The GGSN may send a reply to the mobile station using a new IGMP response mes- 
sage or MLD message in case of Ipv6. 

5 

7. it IS now possible for the MS to take part in the multicast communication session. 



10 Mobility 

The routing area update procedure is followed when a mobile station moves and enters 
a new routing area. The context in the SGSN context response from the old SGSN to the 
new SGSN contains the multicast extensions. However when a mobile station changes 
15 SGSN, the setting up and removal of the GTP Multicast tunnel between the GGSN and 
the SGSNs is dependent on if there is an active context for the given multicast group. If 
the old SGSN has no other remaining listeners to the given multicast group, it removes 
the context and its link to the multicast tree, if the new SGSN has no previous context for 
this multicast group, it needs to attach to the multicast tree. 

20 

QoS for the multicast service in the GPRS network 

The GGSN may receive information about the QoS parameters for the multicast service 
25 from the source directly or indirectly. The information could be received with or without 
request. Based on this information and possibly also information from the mobile stations 
about their requested QoS. the GGSN can set up one or several different multicast trees 
in order to serve different levels of requests and capabilities of the mobile stations, in 
case the GGSN decides that multiple QoS multicast groups should be used, it informs 
30 the individual users about the multicast group that they will t)elong to by sending a new 
multicast group address to them. This information can be provided in the IGMP response 
message or a dedicated message. The GGSN is then responsible for replicating the 
multicast data on to different QoS multicast groups in the PLMN with different QoS bear- 
ers. 



12 



BNSDCXJiD: <WO 03036872A1 J_> 



wo 03/036872 PCT/SE02/01 799 

Multipie ''muiticast context activations" must be invoked by the 6GSN in case of multiple 
QoS multicast groups. 

5 General functionality in the Core Network (CN) 

In fig 4 and 5» the functionality of the GGSN and the SGSN has been illustrated further. 
The steps in fig. 4 and 5 refer to the same events as in the handshake diagram of fig. 3. 

10 Under step 1, the (GMP or MLD Membership report is received from the mobile station, 
MS. 

if there is no multicast context in the GGSN for the multicast group, 1a, the GGSN veri- 
fies the MC group and sets up a connection, i.e. GTP tunnel if tunnels are used, to the 
15 MC source (MCS) and determines the QoS level to be used, lb. 

Moreover, a multicast context is created for the MC group, 1c. 

Subsequently to step la if the answer was yes or step 1c, the mobile station in question 
20 is added to the to the MC group context, Id. 

According to step 2, the GGSN issues a MC context activation to the SGSN in order to 
set up the connection from the GGSN to the SGSN in question, e.g. a GTP tunnel for 
multicast content as shown in fig. 1 and 2. 

25 

When the SGSN receives the MC context activation message from the GGSN, 2, the 
SGSN extend its context of the mobile station in question with the respective multicast 
group, step 2a. if a multicast group not already exist on the SGSN. step 2b, the SGSN 
creates a context for the multicast group, step 2c. 

30 

When the multicast context exist for the MC group in the SGSN the mobile station, MS, 
is added to the MC group context, step 2d. 

Subsequently, the RAN is notified that the mobile station wants to join the MC group and 
35 wait for reply, step 3. 

13 
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In case GTP tunnels are used as explained under fig. 1 and 2, and if there is a not a 
OTP tunnel for the MC group between the GGSN and the SGSN, 3a, such a tunnel is 
created, 3b. 

5 Subsequently, in step 4. the GGSN acknowledges to the SGSN the MG-context activa- 
tion request. 

in step 5, the SGSN notifies the mobile station of the context up-date. Parameters such 
as radio bearer RAB and QoS for the session is conveyed to the mobile station. 

10 

Finally, in step 6, an IGMP response or comparable MLD message is issued to the mo- 
bile station from the GGSN. 

The multicast service subscription data may be present in the HLR / HSS (3G). This data 
15 may include the following: APN, the unique identifier, encryption and decryption keys, 
QoS needed (bit-rate), charging info. 

Advantageously the RAN nodes should be aware of the context extensions for multicast 
to such a level that transmissions may be sent, per cell, when at least one active user is 
20 present is present in a cell. 

Multicast Tunnel Release 

25 When the multipoint PDP-context is deactivated (see e.g. 3GPP TS 23.060). or the host 
leaves the multicast group (e.g. IGMP leave message), the SGSN checks whether the 
host was the last member of a MC-group. 

If other memt>ers exist for the MC-group, the SGSN informs the GGSN that one member 
30 has de-registered from the MC-group. Depending on the data stored in the GGSN, the 
SGSN sends either the host-id or just a message that the counter for the MC-group is to 
be decreased. 

If no more members exist, the SGSN releases the tunnel towards the GGSN. Note that 
35 the tunnel may remain for future use if pre-configured multiplexed tunnels are used. Op- 
tionally, timers may be used to release tunnels after a certain period of inactivity. 

14 
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Advantages of the invention 

5 This invention provides an efficient utilisation of scarce and expensive network re- 
sources in wireless networks. 

Efficient transmission on the Gn and Gp and tu-PS interface is achieved by transmitting 
only a single copy of a packet on each link. This reduces the overall transmission re- 

10 sources needed and limits the need for congestion prevention, (oad balandng algo- 
rithms, etc. when multiple clients for the same multicast group are located in the same or 
different SGSN's. Note that this also applies to scenarios with heterogeneous subscriber 
equipment or access networks, since layering, e.g. multiple media or multiple adaptation 
layers as specified in MPEG-4, of the information can be used as described in the back- 

15 ground chapter. 

Another benefit is the toad reduction on the content provider, e.g. streaming server, 
since the content only needs to be sent once for a whole multicast group. 

20 The multipoint transmission according to the invention is especially advantageous for the 
air interface of mobile systems, especially in situations where resources are limited, such 
as when hundreds of users, present in the same mobile communication cell, are receiv- 
ing the same transmission, 

25 There are many possible applications for mobile multicast sessions according to the in- 
vention. Transmission to spectators at a football arena with replays of the latest goal is 
one example. Traffic information and commercials, e.g. streaming video, within a certain 
geographical area are examples of other applications, which would be interesting to ac- 
cess wirelessly. 
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Terminoloov and Abbreviations 





APN 


Access Point Name 




CN 


core iMetworK 


c. 
0 




ijateway upko ouppori Nooe 




GPRS 


General Packet Radio Service 




GTP 


GPKo Tunnelling Protocol 




HLR 


Home Location Register 




IGMP 


Internet Group Management Protocol 


10 


L2TP 


Layer 2 Tunnelling Protocol 




MC 


Multicast 






Multicast Listener Discovery 




ft Afv 

MS 


Mobile Station 




PDP 


Packet Data Protocol 


15 


PLMN 


Public Land Mobile Network 




PS 


Packet Switched 




QoS 


Quality of Service 




f» A ft 1 

KAN 


Radio Access Network 




RFC 


Request For Comments 


20 


RTSP 


Real-time Streaming Protocol 




SCSN 


Serving GPRS Support Node 




SIP 


Session initiation Protocol 




TE 


Terminal Equipment 




TEID 


Tunnel End Point Id 


25 


TID 


Tunnel Identifier 




UC 


Unicast 




UMTS 


Universal Mobile Telecommunications 




WAP 


Wireless Application Protocol 
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Patent claims 

1 . Method of establishing a multicast service in a packet radio data network com- 
prising at least a gateway node (GGSN). at least one serving node (SGSN) cou- 

5 pled to the gateway node, a plurality of radio access nodes (RAN) coupled to the 

serving node (SGSN), the packet radio network transporting packet data from an 
external packet data network to mobile stations (MS) wirelessly attached to radio 
access nodes (RAN), the method comprising the steps of 

10 - a mobile station (MS) issues a membership report message indicating that the 

mobile station wishes to receive content of a specific multicast group (1), 

- the gateway node (GGSN) receives the message and issues a multicast context 
activation message to the serving node (SGSN) (2), 

15 

- the serving node (GGSN) informs the radio access network (RAN) that the mo- 
bile station is joining the respective multicast group (3), 

- the serving node (SGSN) sends a multicast activation response to the gateway 
20 node (GGSN) (4), 

- the serving node (SGSN) notifies the mobile station of the radio access bearer 
and the quality of service for the multicast session (5). 

25 

2, Method according to claim 1 , in which subsequently 

- the gateway node (GGSN) issues a multicast report message to the mobile sta- 
tion, whereupon the given mobile station is ready for taking part in the requested 

30 multicast session. 



3. Gateway node (GGSN) establishing a multicast service in a packet radio data net- 
work comprising at least one serving node (SGSN) coupled to the gateway node, a 
35 plurality of radio access nodes (RAN) coupled to the serving node (SGSN). the 

packet radio network transporting packet data from an external packet data net- 
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work to mobile stations (MS) wirelessly attached to radio access nodes (RAN), 
whereby the gateway node (GGSN), 

- upon receiving a multicast membership report from a mobile station examines if 
there is a context for the multicast group in the gateway node (GGSN), 

- if no multicast group exists, sets up a connection to the multicast source from the 
gateway node (GGSN). 

- creates a context in the gateway node (GGSN) for the multicast group 
• adds the mobile station to the multicast group 

- sends a multicast context activation message to the serving node (SGSN) from 
which the membership report message appeared in order to set up a connection 
with the serving node (SGSN). 

4. Gateway node according to claim 3. in which subsequently the gateway node 
(GGSN) upon being informed that a multicast connection has been established 
between a respective serving node (SGSN) and the mobile station 

- responds to the mobile station that such a connection has been established from 
the multicast source to the mobile station. 

5. Serving node (SGSN) establishing a multicast service in a packet radio data net- 
work comprising at least a gateway node (GGSN), a plurality of radio access 
nodes (RAN) coupled to the serving node (SGSN), the packet radio network trans- 
porting packet data from an external packet data network to mobile stations (MS) 
wirelessly attached to radio access nodes (RAN), whereby the serving node 
(SGSN) 

- upon receiving a multicast context activation from a gateway node (GGSN), ex- 
tends the context of the mobile station in question with the respective multicast 
group. 

18 
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- if a multicast group does not already exist on the serving node (SGSN), the 
serving node (SGSN) creates a context for the multicast group. 

5 - the serving node (SGSN) adds the mobile station. MS, to the MC group context, 

- the serving node (SGSN) notifies the RAN that the mobile station wants to join 
the MC group. 

10 

6. Serving node according to claim 5, in which subsequently 

- if no connection for the multicast group already exists between the gateway node 
(GGSN) and the serving node (SGSN) in question 

15 

- the serving node creates such a connection. 



7. Serving node according to claim 6, in which subsequently 

20 

- the serving node (SGSN) acknowledges the multicast context activation request 
from the gateway node (GGSN). 



25 8. Method according to claim 1 or 2 in which the membership report message from 

the mobile station is an IGMP membership report message 

9. Method according to claim 1 or 2 in which the membership report message from 
30 the mobile station is a MLD listener report message. 



10. Method according to any previous claim, wherein the connections are formed of 
GTP tunnels. 

35 

11. Method according to any of claims 1 - 8» wherein the connections are based on 

memberships to IP multicast addresses. 
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12. Mobile station establishing a multicast service in a packet radio data network com- 
prising at least a gateway node (GGSN), at least one serving node (SGSN) cou- 
pled to the gateway node, a plurality of radio access nodes (RAN) coupled to the 
serving node (SGSN), the packet radio network transporting packet data from an 
external packet data network to mobile stations (MS) wirelessly attached to radio 
access nodes (RAN), whereby the mobile station subsequently to having initiated 
a PDP context procedure informs the gateway node of its interest for a specific 
multicast service by issuing a membership report such as IGMP or MLD, where- 
upon the mobile station receives a notification context update and a multicast re- 
port response, whereupon the mobile station can engage in the multicast commu- 
nication session 



0303687aAlJ_> 



20 

SUBSTITUTE SHEET (RULE 26) 



wo 03/036872 



PCT/SE02/01799 



1/5 



RTR20 



MG7 Ml 



M3 






M4 



M5 



M6 



MG7 M7 



M8 



MG8 



RTR10 




GTPT8 

GiTPT? 



RAN1 




RAN2 



RAN3 



RTR30: 



RAN4 



M10 






RAN 5 















SGSN1 



GTPT8 

B^n=?T7 



GTPT7 




SGSN2 



G7PT8 



|ggsni 






\ 




MCS 


GTPT8 

1 
i 

j 





Fig. 1 



3NSDOCID: <WO 03036872A1_L> 



wo 03/036872 



PCT/SE02/01799 



2/5 



RTR20J 



MG7 




RTR101 



— -— 'GTPT? 



RTS15: 



GtPT8 



MG8 


M3 




MG7 


1m4 



M5 



MG7 



RAN1 



RAN2 




RAN3 




SGSN1 



GTPT7 



w _ — — 



RTR30; 



TPT7 
GTPT8 



GTIPT8 



GTPTiZ 



RAN4 


• 


■ ■ 





SGSN2 



RAN5 




GTPrre 



is 




MCS 



Fig. 2 



03036872A1J_> 



c 



wo 03/036872 



PCT/SE02/01799 



3/5 



MS 



RAN 



SGSN 



GGSN 



MCS 



1. Multicast Report 



5. Notification 



6. Multicast rep ort response 



■4 



RAN Set-up 



of context update 



7. Multicast communication sess ion 



Multicast cont< ^xt activation 



(RAB, QoS) 



4. Multicast confa^xt activation response 



Fig. 3 



One or more events 
Single everrt 



NSDOCID: <WO 0303e872A1_L> 



r 



WO 03/036872 PCT/SE02/01 799 



4/5 



1. 

IGMP Membership 
Report received 
from MS 



Yes 




1b. 

Verify the MC-group, set up 

the connection to the 
MC-«ource from the GGSN 
and determine the QoS 
to t>e used 



I 



1c. 

Create a context in the 
GGSN Ibrthe MC-group 



Id. 

Add MS to the MO 
Group context 



1 



Send MC context 

activation 
to SGSN in order to 
set up a connection 
with the SGSN 



Fig. 4 -GGSN 



6. 

Respond to the MS 



MS Mobile Station 
MC Multicast 



BNSDOCID: <WO 03036872Al_l„> 



wo 03/036872 



PCT/SE02/01799 



5/5 



2. 

MC context 
acth/alion received 
from GGSN 



2a. 

Extend the context 
of the MS of the SGSN 
with the MC-group 



No 



2c. 

Create a context for 
the MC group in SGSN 




2d. 

Add MS to the MC- 
group context of the SGSN 



3. 

Notify the RAN that the MS 
wants to jointhe MC-group and 
wait for reply 



No 



£ 



3b. 

Create a connection 
between GGSN and SGSN 
for the MC group. 



Fig, 5 -SGSN 



3a. 

Is there a connection for the 
MC-group between GGSN 
and SGSN? 



Yes 



Acfcnowfedge the MC context 
activation request received 
from the GGSN 



1 



5. 

Notify MS of context up-date 



NSDOCID: <WO ^03036872A1 I > 



INTERNATIONAL SEARCH REPORT 



International application No. 

PCT/SE 02/01799 



A. CLASSIFICATION OF SUBJECT MATTER 






IPC7: H04L 12/18. H04L 12/56 

According to International Patent CJassifScation (IPC) or to both national classification and IPC 




B. FIELDS SEARCHED 


Minimum documentation searched (classincation system followed by classification symbols) 

IPC7: H04Q, H04L 


Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 

SE,DK,FI»NO classes as above 


£lectronic data base consulted during the international search (name of data base and, where practicable, search terms used) 


C. DOCUMENTS CONSIDERED TO BE RELEVANT 


Category* 


Citation of document, with indication, where appropriate, of the relevant p2ks%ai^^es 


Relevant to claiirt No> 


X 


WO 0057601 Al (NOKIA NETWORKS 0Y)» 28 Sept 2000 
(28.09.00), page 5, line 29 - page 8, line 35, 
figure 3 


1-8,10-12 


P.A 


WO 0251072 Al (NOKIA CORPORATION), 27 June 2002 
(27,06.02), figure 2, abstract 


1-12 


A 


US 6304558 Bl (MYSORE, J- P.). 16 October 2001 

(16.10.01), column 1, line 65 - column 3, line 13 


1-12 


P.A 


US 2002026525 Al (ARMITAGE, G.J.), 

28 February 2002 (28.02.02), abstract 


1-12 


1 1 Further documents are listed in the continuation of Box C. | )(| See patent family annex. 


* Special categories of cited documoits: 

"A" document defining the general state of the art which is not considered 
to be of particular relevance 

'E* earlier application or patent but published on or after the intematianal 
filing date 

*L* document which may throw doubts on pnority ciaii3i(s} or which is 
cited to establish the publication date of another dtation or other 
special reason (as spedlied) 

'O" document refemng to an oral disdosure, use, exhibition or other 
means 

"P" document published prior to the international filing date but later than 
the phonty date claimed 


later document published after the international filing date or priority 
date and not in conflict with the application but cited to understand 
the principle or theory underlying fte invention 

'X* document of particular relevance: the claimed invention cannot be 
coiuidered novel or cannot be conadered to involve an inventive 
5tep wfien the document is taken aloae 

"y* document of particular relevance: the claimed invention cannot be 
considered to involve an inventive step when the document 1$ 
combined \vith one or more other such documents, such comhinauon 
being obvious to a person skilled in the art 

document member of the same patent family 


Date of the actual completion of the international search 

17 January 2003 


Date of mailing of the international search report 

2 7-01- 2003 


Name and mailing address of the ISA/ 
Swedish Patent Office 
Box 5055. S-102 42 STOCKHOLM 
Facsimile No. + 46 8 666 02 86 


Authorized officer 

Stefan Hans son /OGU 

Telephone No. + 46 8 782 25 00 



Form PCT/ISA/210 (second sheet) (July 199S) 

BNSDCXIID: <W O • 03Q36a7aA1 I > 



INTERNATIONAL SEARCH REPORT 

isfonna&on on patent family members 



30/12/02 



Intematioaal applicatioa No. 

PCT/SE 02/01799 



Patent document 


Publication 


Patent family 


Publication [ 


cited in search report 


date 


member(s) 


date 1 



wo 


0057601 


Al 


28/09/00 


AU 
EP 

us 


3417499 A 
1163758 A 
2002049066 A 


09/10/00 
19/12/01 
25/04/02 


wo 


0251072 


Al 


27/06/02 


AU 
FI 


1719802 A 
20002770 A 


01/07/02 
19/06/02 


us 


6304558 


Bl 


16/10/01 


BR 
EP 
WO 


0010526 A 
1186130 A 
0074288 A 


19/02/02 
13/03/02 
07/12/00 


us 


2002026525 


Al 


28/02/02 


NONE 







Form PCT/ISA/210 (patent family annex) (July 1998) 

3NS0OCI0:<WO ^0303ea72Al \j> 



